Existing industry specifications describe how many Internet Protocol (IP) Multimedia Subsystem (IMS) services can coexist on the same device. Group Special Mobile Association, GSMA, Official Document NG.102 describes the native coexistence of Voice over Long Term Evolution (LTE) (VoLTE) and Rich Communication Suite (RCS) functionality in the same device or user equipment, UE, allowing them to use the same public identity (IP Multimedia Public Identity (IMPU)) defined in section 13.4 of Third Generation Partnership Project (3GPP) Technical Specification (TS) 23.003 Release 8 and later, and supporting single and dual IMS registrations.
Several possible configurations for a NG.102 device are allowed:                1) VoLTE and RCS functions use a single IMS registration;        2) VoLTE and RCS use dual IMS registrations with the same IMS core; and        3) VoLTE and RCS use dual IMS registrations with two separate IMS cores.        
However, these scenarios are not fully resolved when it comes to the IMS identity model and Extensible Markup Language (XML) Configuration Access Protocol (XCAP) authentication for the XCAP (Ut) traffic from the NG.102 device. XCAP is used by both:                a) a VoLTE client (for access to supplementary services profiles from 3GPP Multimedia Telephony (MMTel) specifications); and        b) an RCS client (e.g., for access to an Open Mobile Alliance (OMA) presence based service when the avatar of a contact needs to be fetched, for management of the resource lists for presence subscriptions and authorization rules for SIMPLE Presence, or for the management of personal network blacklists).        
XCAP protocol allows both the VoLTE client and the RCS client to read, write, and modify application configuration data and presence data stored in XML format on a server (e.g., Multimedia telephony server, MMTel). XCAP provides the subscribers with the freedom to self-provision their own services. XCAP uses the HTTP methods PUT, GET, and DELETE to operate on XML documents stored in the servers and is specified in 3GPP TS 24.623, 3GPP TS 33.222 and Internet Engineering Task Force Request for Comment, IETF RFC 4825.
XCAP Authentication:
The XCAP traffic does not go through the session border controller or Proxy Call Session Control function, PCSCF, of the IMS core, but through an Authentication Proxy, AP, instead. The main purpose of the AP is to authenticate user requests to read, write, and modify application configuration data and presence data.
The AP is configured as an HTTP reverse proxy. That means that the Fully Qualified Domain Name, FQDN, of the Application Server, AS, (e.g. MMTel, presence server, (or XML Document Management Server, XDMS) is configured to the AP in such a way that the IP traffic intended to the AS is routed to the AP. The AP performs the authentication of the device or UE. After the authentication procedure has been successfully completed, the AP assumes the typical role of a reverse proxy, i.e. the AP forwards HTTP requests originating from the UE to the correct AS, and returns the corresponding HTTP responses from the AS to the originating UE.
Authentication of XCAP request is based on Generic Bootstrapping Architecture (GBA)/Generic Authentication Architecture (GAA) infrastructure. GBA provides the “bootstrapping of application security” to authenticate the subscriber based on Authentication Key Agreement, AKA, protocol as specified in 3GPP TS 33.102. The GBA/GAA are specified in 3GPP TS 33.220 and 3GPP TS 33.222. To describe existing XCAP authentication, the AP is represented by two functions:
The Network Application Function, NAF:
NAF is the reverse HTTP proxy and handles the security relation with the UE and relieves the AS of this task. Based on Generic Bootstrapping Architecture, GBA, the NAF can assure the AS that the request is coming from an authorized subscriber.
The Bootstrapping Server Function, BSF:
BSF and the UE shall mutually authenticate using the AKA protocol, and agree on session keys (KS_NAF) that are afterwards applied between the UE and the NAF. The BSF shall be able to acquire the GBA user security settings (GUSS) from the Home subscriber server, HSS, in the IMS core. Physically, the NAF and BSF can be different servers. Actually the BSF is in the home network whereas the NAF can be located in a visited network. The above procedure applies for a single IMS registration performed by the UE or the NG. 102 device.
It is however unclear in current industry specifications if a single infrastructure for Generic Bootstrapping Architecture (GBA)/Generic Authentication Architecture (GAA) used for communication services (e.g., for XCAP authentication handling) can be used for the cases when dual IMS registration is used, with either a single IMS core or two IMS cores for a device that uses more than one service function, for example a Voice over Long Term Evolution (LTE) (VoLTE) client/function and a Rich Communication Suite (RCS) client/function. The VoLTE and RCS client/function could be implemented natively within the device or can be implemented as a standalone application downloadable on a device from Application stores hence accessible as a separate application on the user's device.
The existing solution provides the following device configurations that use dual Internet Protocol (IP) Multimedia Subsystem (IMS) registration for the coexistence between VoLTE and RCS clients/functions:                Case 1—Dual registration with one IMS core                    The native implementations in the device of a VoLTE client and an RCS client use same or different IP Multimedia Public Identity (IMPU), but in any case, different IP Multimedia Private Identities (IMPIs) when they register towards the same IMS core. When using Extensible Markup Language (XML) Configuration Access Protocol (XCAP), the operator requirements are for these clients and the networks to be able to use the same authentication method for all XCAP traffic, such as Generic Bootstrapping Architecture (GBA)/Generic Authentication Architecture (GAA) using the same key sets (available from the Universal Integrated Circuit Card (UICC) or device).                        Case 2—Dual registration with two IMS cores                    The native implementations in the device of a VoLTE client and an RCS client can use same or different IMPU/IMPI pairs but register towards two different IMS cores. If using the same IMPU/IMPI, when using XCAP, the requirements are for these clients and the networks to be able to use the same authentication method for all XCAP traffic, such as GBA/GAA using the same key sets (available from the UICC or device).                        